Tamper evident system for modification and distribution of secured vehicle operating parameters

ABSTRACT

Systems and methods of securing, distribution and enforcing for-hire vehicle operating parameters are described whereby a first computer system maintaining the parameters generates a data packet that is distributed to a second computer system which acts as a meter (such as a taximeter, limousine meter or shuttle meter) for the for-hire vehicle. The first computer system may secure or encrypt the data packet according to a security protocol associated with the second computer system. Once the second computer system receives the data packet, it may validate and extract the operating parameters contained within it. The second computer system may then store the operating parameters and operate according to the parameters by, for example, calculating fares for passengers that make use of the for-hire vehicle associated with the second computer system. The second computer system may include a secure segment that is attached to the for-hire vehicle and a non-secure segment that may be easily removed to prevent theft or for repairs.

INCORPORATION BY REFERENCE TO ANY PRIORITY APPLICATIONS

Any and all applications for which a foreign or domestic priority claimis identified in the Application Data Sheet as filed with the presentapplication are incorporated by reference under 37 CFR 1.57 and made apart of this specification.

BACKGROUND

The present disclosure relates to the field of for-hire vehicles such astaxis, limousines, shuttles, buses or any other vehicle that providesshared transportation or transports one or more passengers betweenlocations of the passengers' choice.

A for-hire vehicle (FHV) generally charges fares based on severalvariables. The variables may include the distance traveled, the timespend traveling, the number of passengers hiring the FHV, etc. The costassociated with each of these variables is often set by a regulatoryagency that regulates the for-hire vehicles (“FHVs”) within itsjurisdiction of control. Typically, the jurisdiction of controlcorresponds to a city or metro area, however, in some cases it may be acounty, several counties, or even an entire state. Regulatory agenciesmay also issue licenses to operate FHVs within their jurisdiction ofcontrol. The licenses may correspond to a timeframe, such as a year, orthey may permit the operation of a FHV only within a particular areawithin the jurisdiction of control. In some jurisdictions, medallionscorresponding to the license may be issued. The medallions may beaffixed to the FHV and indicate type of license associated with the FHV.

The calculation of fares for a trip in a FHV is typically done by ameter. A meter is programmed with the variables used to calculate thefare along with the values associated with those variables that theregulatory agency has determined. When a FHV is hired for a trip, themeter is typically started and then when the trip is over the meter isstopped. In most cases the fare amount is displayed in real time via adisplay that is part of the meter. Currently meters are separate devicesthat are affixed to a FHV. FHV meters are programmed by the regulatoryagency regulating the FHV to which the meter is affixed.

Unfortunately, the business of operating for-hire vehicles (“FHVs”) issusceptible to fraud. As a result, regulatory agencies seal FHV metersso that no one may tamper with the meter, or the data within the meter,without detection. Once the regulatory agency sets the fare rates forthe meter, the entire meter is then locked with a physical seal thatprevents, or shows evidence of, tampering. Once the meter is sealed, allcomponents that are part of the meter, such as fare displays and receiptor trip sheet printers are also sealed. The physical sealing processmakes updating rates particularly difficult. If the regulatory agencywishes to change rates, an agent of the regulatory agency must break theseal on each meter in the jurisdiction, perform the necessary updates,then reseal the meter. The update process can be very labor intensive assome regulatory agencies may regulate several thousand FHV meters, eachof which needs to be manually opened, updated and resealed when updated.The process can also be rather expensive. Some regulatory agencies passthe cost of opening and resealing the meter onto the FHV fleet operator.In addition, the FHV fleet operator also incurs an opportunity cost byhaving to remove a FHV from the fleet so that its meter can be updated.

Since updating meters is time consuming and expensive, it tends to bedone as little as possible. In some cases this may lead to missedrevenue opportunities. For example, in some jurisdictions, if fuelprices increase substantially above the rate base, fleet owners may beallowed to help offset the fuel price increase by requesting that theregulatory agency permit a fuel surcharge. Fuel surcharges, however, areoften temporary since they may only apply when fuel prices are unusuallyhigh. Thus, implementing a surcharge often requires two modifications tothe meter; one modification to include the fuel surcharge when fuelprices increase, and a second when fuel prices return to the existingrate base. Thus, since the regulatory agencies generally bear the directcost of updating the meters, they may resist implementation of fuelsurcharges because the cost of implementing the surcharge (updating themeters) is charged against the agency's budget. Further, this cost mayeventually be passed on to the consumer through higher regulatory agencyfees. In addition, regulatory agencies may also wish to increase farestemporarily as a result of a special event in order to take advantage ofperiod when FHV use may be high. Since a change in fares due to aspecial event is limited in duration, special event surcharges sufferthe same problems as fuel surcharges; the cost of updating the fareinformation in the meter is often higher than the extra revenue thatcould be generated by incorporating the surcharge.

In addition, since the entire meter is sealed by the regulatory agency,repairs to the meter require an agent to reseal the meter before it isreturned to service. Often times, the portion in need of repair is notrelated to the aspects of the meter that are regulated, such ascalculation of fares. For example, if the display screen of the meterneeds to be repaired or replaced, the meter must be resealed by theregulatory agency before the meter is returned to service even thoughthe display screen may not be the portion of the meter which is subjectto fraud. Since the meter must be resealed for every repair, meters areunnecessarily expensive to repair and may out of service longer thanneeded.

SUMMARY

The present disclosure focuses on systems and methods for updating theparameters of a for-hire vehicle meter without requiring physicallybreaking the regulatory seal of the meter and then resealing the entiremeter. The present disclosure describes embodiments that would allow forrepair of the non-regulated portions of the FHV meter (such as a screendisplay) without requiring the regulatory agency to physically resealthe meter. In addition, the present disclosure describes embodimentsthat may allow the non-secure portions of the FHV meters to be movedfrom one FHV to another without requiring the intervention of aregulatory agency.

One embodiment of the disclosure describes a for-hire vehicle metercomprising a secured, tamper-evident portion. By separating the portionsof the meter under regulatory control from the portions of the meter notunder regulatory control, repairs to the meter may not require resealingof the entire meter. The secured, tamper-evident portion may comprise atamper-evident, tangible, computer-readable medium storing softwareinstructions for receiving updated FHV operating parameters, such asfare information. The received operating parameters may be sealed by theregulatory agency using a security protocol, such as encryption. The FHVmeter comprises data for decrypting the operating parameters. Oncedecrypted, the FHV meter may store the operating parameters and operateaccording to the updated parameters. The tamper-evident portion of themeter may also comprise a tampering indicator. The tamper indicator mayindicate a first state when someone has tampered with the meter, such aswhen someone has attempted to load non-regulatory, unapproved operatingparameters onto the meter. The tamper indicator may also indicate asecond state when no one has tampered with the meter.

The present disclosure also describes a method for updating theoperating parameters of a for-hire vehicle (“FHV”) meter or computersystem, whereby a computer system for defining FHV operating parametersgenerates a data packet that is distributed to one or more FHV meters.The computer system may allow for the definition, maintenance, andmodification of FHV parameters. The computer system may also maintaindata associated with the one or more FHV meters, including data uniquelyidentifying the meters. The computer system may also have access to asecurity protocol of the FHV meters that is used by the FHV meters todecrypt data. When the operator of the computer system wishes to updatethe operating parameters of the FHV meters, it may generate a datapacket containing the new parameters. The computer system may thensecure the data packet according to the security protocol of the FHVmeter. Once the data packet has been generated and secured, it may thenbe distributed to the FHV meter for which it is intended.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram showing one embodiment of a parametermaintenance computer system in communication with more than one for-hirevehicle meter.

FIG. 2 is a block diagram showing one embodiment of a for-hire vehiclemeter.

FIG. 3 is a block diagram showing one embodiment of a parametermaintenance computer system.

FIG. 4 is a flowchart showing the temporal flow of data for generating asecure data packet of for-hire vehicle parameters in one embodiment of aparameter maintenance computer system.

FIG. 5 is a flowchart showing the temporal flow of data for processing asecure data packet in one embodiment of a for-hire vehicle meter.

DETAILED DESCRIPTION OF EMBODIMENTS

Embodiments of the disclosure will now be described with reference tothe accompanying figures, wherein like numerals refer to like elementsthroughout. The terminology used in the description presented herein isnot intended to be interpreted in any limited or restrictive manner,simply because it is being utilized in conjunction with a detaileddescription of certain specific embodiments of the disclosure.Furthermore, embodiments of the disclosure may include several novelfeatures, no single one of which is solely responsible for its desirableattributes or which is essential to practicing the embodiments of thedisclosure herein described.

FIG. 1 is a block diagram showing one embodiment of parametermaintenance computer system 120 in communication with more than onefor-hire vehicle (“FHV”) meter 100, 101, 102. Parameter maintenancecomputer system 120 may be a computer system responsible for themaintenance of FHV parameters. In general, FHV parameters are valuesdefining the operation of for-hire vehicles. A set of FHV parameters maybe stored in FHV meters associated with a FHV, such as FHV meter 100,101 and 102. In general, FHV parameters are configurable and may changeover time. Regulatory bodies may set regulations dictating the terms bywhich for-hire vehicles (“FHVs”) may operate, and FHV parameters may bestored in FHV meter 100 reflecting those terms. The regulatory bodiesmay change the regulations, in some cases temporarily, compared to whenthe FHV meter was installed on its associated FHV. Accordingly, the FHVparameters require updating from time to time.

For-hire vehicle (FHV) parameters may include, for example, valuesdefining fees based on time and distance traveled. In one embodiment,the FHV parameters may include a distance increment type valueindicating the type of distance increment for which fares should becalculated such as, for example, meters, kilometers, or miles. FHVparameters related to defining fees based on time and distance traveledmay also include a distance increment indicating the increment of thedistance type to calculate fares. For example, the increment may be 0.5of a mile, or 100 meters, or alternatively, 0.1 kilometers. Theparameters may also include a fee value per distance increment, such as,for example $0.50. Several parameters may be combined to define the feesbased on time and distance traveled for a particular trip taken by aFHV. For example, the distance increment type may be miles, the distanceincrement may be 0.125 of a mile, and the fee per distance traveled maybe $0.25. Thus, if a passenger used a FHV vehicle for 0.5 miles, theymaybe charged a $1.00 fare.

FHV parameters defining fees based on time and distance traveled mayalso include time related parameters. In one embodiment, the FHVparameter may include a time increment type, such as second or minute,that defines the type of time used to calculate time based fares. TheFHV parameters may also include a time increment such as 1 second or 0.5minutes. In one embodiment, a fee per time value may also be among theFHV parameters. For example, a fee per time value (such as $26) may beassociated with a particular time increment type (such as hours) andtime increment (such as 1 hour), resulting in a fee per time value of$26 per 1 hour. In one embodiment, time based parameters may be used inlieu of distance based parameters. This may occur for example in a FHVthat operates based on a fixed tariff such as a limousine. In otherembodiments, time based parameters may be used in conjunction withdistance based parameters. In other embodiments, time based parametersmay only be used during times when a FHV is hired but not moving, anddistance based parameters may be used when the vehicle is moving. TheFHV parameters may include, in such embodiments, a value indicating howtime and distance parameters are to be used in relationship to eachother. For example, in one embodiment the time-distance relationshipparameter may be “distance only” or it may be “time at idle.” In otherembodiments, numeric values may be used instead of string values.

In some embodiments, regulations affecting for-hire vehicles (“FHVs”)may set special fares based on a geospatial point. The special fare mayaffect the time and distance-traveled parameters, or it may be anadditional flat fare added to the regular time and distance-traveledparameters. For example, in one embodiment, there may be a special ratebased on a geospatial point corresponding to the airport. The fee maybe, for example, $2.00. Thus, in such embodiments, $2.00 may be added toa fare when a passenger using the FHV is picked up at the airport. Inother embodiments, the geospatial point may affect the time anddistance-traveled parameters. For example, if a passenger is picked upat the airport, they may be charged a fare of $0.32 per half kilometeras opposed to $0.30 per half kilometer.

In some embodiments, the FHV parameters define variable operating costsurcharges. In some embodiments, variable operating cost surcharges maybe applied by a regulatory agency to help offset an unexpected cost tothe FHV operator. For example, a fuel surcharge may be added to fares inorder to offset unexpected rise in fuel prices. The FHV parameters maydefine the surcharge as a flat surcharge (one charge per fare) or as anadditional per-distance surcharge (for example, and extra $0.05 permile). In one embodiment the FHV parameters relating to variableoperating cost surcharges may indicate a surcharge type. The surchargetype may in some embodiments be a string, such as “flat” or“per-distance.”

The FHV parameters may also include a parameter indicating a surchargefor fare initiation or fare termination. A fare initiation fee may be aone time fee that is charged at the start of a fare, or trip. If, forexample, the fare initiation fee is $2.35, a passenger might be chargedat least $2.35 for the trip. As the trip progresses, the passenger maybe charged additional time and distance-traveled fees according to otherFHV parameters stored on the FHV meter.

In some embodiments, for-hire vehicle (“FHV”) parameters may be groupedtogether. In such embodiments, group-FHV parameters may apply to acollection of FHV parameters to indicate that they are to apply onlywhen the conditions of the group-FHV parameters are met. For example, insome embodiments, it may be desirable to limit the application of FHVparameters to a specific period of time. In such embodiments, there maybe additional group-FHV parameter indicating the start time and/or endtime for the set of FHV parameters. For example, special rates may applyto weekends, holidays or special events. Accordingly, the FHV parametersmay be include a start date and end date that correspond to the weekend,holiday or special event. In other embodiments, it may be desirable todefine FHV parameters for mutually exclusive geospatial regions withinthe FHV's operating region. For example, suppose a FHV serves a northregion and south region. The north region may be larger and lessdeveloped than the south region. As a result, when a FHV makes a tripfrom the airport into the north region, there is low likelihood that theFHV will be able to pick up another passenger in the north region tobring back to the airport. Accordingly, fare rates for the north regionmay be higher than for the south region where the FHV is more likely topick up another passenger quickly. In this example, FHV parameters forthe north region may be different from FHV parameters from the southregion. The north region's FHV parameters may be grouped by onegroup-FHV parameter defining a first geospatial polygon (the northregion) and the south region's FHV parameters may be grouped by adifferent group-FHV parameter defining a second geospatial polygon (thesouth region).

Returning to FIG. 1, parameter maintenance computer system 120 may beresponsible for maintaining the FHV parameters and packaging the FHVparameters in a manner that FHV meters 100, 101, and 102 can interpret.While certain examples of FHV parameters are provided herein, oneskilled in the art can appreciate that other FHV parameters may bedefined, maintained and configured by parameter maintenance computersystem for deployment on FHV meters 100, 101, and 102, and suchparameters should not be deemed limited by the examples provided herein.

In one embodiment, parameter maintenance computer system 120 may be acomputer system operated by an entity responsible for the regulation offor-hire vehicles. For example, parameter maintenance computer system120 may be operated by New York City Taxi and Limousine Commission orthe Nevada Taxi Cab Authority. In another embodiment, parametermaintenance computer system 120 may be operated by a company thatoperates a fleet of for-hire vehicles (“FHVs”). The company may operatein a jurisdiction that allows the update of for-hire vehicles by fleetcompanies as opposed to a regulatory agency.

In one embodiment, the FHV parameters may be distributed overdistribution network 130. Distribution network 130 may be, in someembodiments, a computer network. Depending on the embodiment,distribution network 130 may comprise one or more of any type ofnetwork, such as one or more local area networks, wide area networks,personal area networks, telephone network, and/or the Internet, whichmay be accessed via any available wired and/or wireless communicationprotocols. Thus, distribution network 130 may comprise a secure LANthrough which FHV meter 100 and parameter maintenance computer system120 may communicate, and distribution network 130 may further comprisean Internet connection through which FHV meter 100 and parametermaintenance computer system 120 communicate. Any other combination ofnetworks, including secured and unsecured network communication links,are contemplated for use in the systems described herein.

In another embodiment, distribution network 130 may utilize manpower andnon-transitory tangible computer readable media to distribute FHVparameters from parameter maintenance system 120 to FHV meter 100. Forexample, parameter maintenance system 120 may write the FHV parametersto a portable non-transitory computer medium such as a floppy disk, USBflash drive, memory card, portable hard drive, etc. A person may thendistribute the FHV parameters to FHV meters 100, 101 and 102 byphysically connecting the computer readable medium to each FHV meter inthe network. Once connected, FHV meter 100 may then read the FHVparameters from the computer readable medium and configure itselfaccordingly.

In one embodiment, security breach messages may be sent from FHV meters100, 101 and 102 to parameter maintenance computer system 120. In suchembodiments, FHV meters 100, 101 and 102 may comprise a wirelesstransmitter and distribution network 130 may be a wireless network asdescribed above. When FHV meters 100, 101 and 102 detect a securitybreach, they may generate a security breach message and transmit it viadistribution network 130 to parameter maintenance computer system 120.In some embodiments, parameter maintenance computer system 120 may senda “kill” message to a FHV meter from which parameter computer system 120has received a security breach message, providing an extra layer ofsecurity. In other embodiments, parameter maintenance computer systemmay issue a warning, such as graphical display, email alert, electronicalert, etc, upon receipt of a security breach message. Conditionstriggering a security breach message are described in more detail withrespect to FIG. 2.

FIG. 2 is a block diagram showing one embodiment of FHV meter 100. Inone embodiment, FHV meter 100 may be a dedicated computing device thatattaches to, or on, a FHV and has external interfaces for communicatingwith other computer systems attached to, on, or in the FHV. In otherembodiments, FHV meter may be a separate computing module that is partof the existing computer system of the FHV. In such embodiments, the FHVmeter may be not be visible from within the interior of the FHV meter,and the FHV meter may make use of existing input/output devices of theFHV for displaying information, such as fare information, to the driverand passenger of the FHV.

In one embodiment, FHV meter 100 is configured to interface withmultiple devices and/or data sources, such as in the exemplary networkof FIG. 1. FHV meter 100 may be used to implement certain systems andmethods described herein. For example, in one embodiment, FHV meter 100may be configured to calculate fares for passengers that hire for-hirevehicles (“FHVs”). FHV meter 100 may also be configured to receive anddecrypt FHV operating parameters and operate according to thoseparameters. The functionality provided for in the components and modulesof FHV meter 100 may be combined into fewer components and modules orfurther separated into additional components and modules.

In one embodiment, FHV meter 100 comprises secure tamper evident segment(“secure segment”) 205. Secure segment 205 represents the components andmodules of FHV meter 100 that must be secure from tampering, or showevidence of tampering, in order to abide by the regulations and lawsgoverning for-hire vehicles (“FHVs”). In some embodiments, securesegment 205 may be self destructing, that is, if someone tampers withsecure segment 205, the components and modules of secure segment 205will no longer operate. For example, the storage medium storing softwareinstructions for the modules of secure segment may break, or split, ifthere is an attempt to remove the storage medium from FHV meter 100. Inother embodiments, if someone tampers with secure segment 205, FHV meter100 might send a signal to parameter maintenance computer system 120containing a security breach message. In one embodiment, the degree oftampering detected may advantageously signal different levels ofresponse. For example, if the tampering is physical or certain (forexample a secure component is removed or replaced), FHV meter 100 mightautomatically shut down. If the tampering is only likely but not certain(for example a signal security check is invalid) then a security breachmessage indicating a warning signal might be triggered so that theregulatory agency or fleet owner can inspect the meter.

In some embodiments, secure segment 205 may be fixed to the FHV. In suchembodiments, the portions of FHV meter 100 that are not in securesegment 205 (“unsecure portion”) may be removed from the FHV fornecessary repairs. In some embodiments, the unsecure portion may behoused in one casing allowing for easy removal from the FHV for repairor updates. This may allow, for example, the driver to remove theunsecured portion from the for-hire vehicle when it is not in operationin order to prevent theft. The driver may then reconnect the unsecureportion on his next shift without requiring the oversight of aregulatory agency. In other embodiments, the individual components ofthe unsecure portion may be removed. In some embodiments, the unsecureportion may be the same for every FHV meter in the exemplary networkconfiguration of FIG. 1. Such a configuration may allow for easy repairof the components of the unsecure portion without requiring a regulatoryagency to reseal the entire meter. In addition, this embodiment may alsopermit drivers to pick up any of a group of unsecured portions as theystart their shift thus rendering the need to pre-assign the unsecuredportion of the meter to a particular driver or vehicle.

In some embodiments, secure segment 205 and the unsecure portion may beconnected via a custom interface such as interface 255. The interfacemay comprise, in some embodiments, a unique shape or design such thatonly an unsecure portion and a secure segment 255 of the same make ormodel may be connected. For example, the unsecure portion may comprisean interface in the shape a male “T” shape and the secure segment maycomprise an interface 255 of a female “T” shape.

In one embodiment, a visual indicator of tampering may be adhered to thecomponents of secure segment 205 so that if someone tampers with securesegment 205, the indicator will be broken. The visual indicator mayindicate one state when no one has tampered with secure segment 205, andanother state when someone has tampered with it. For example, selfdestructing tape may be used to wrap the physical portions of securesegment 205 so that if they are changed or replaced the tape breaks. Thetape may indicate a first state (un-torn) when no tampering with securesegment 205 has occurred. The tape may indicate a second state, (torn)when tampering has occurred. In another embodiment, secure segment 205may be implemented via a software module. The module may monitor readsand writes to and from the modifiable data stores of secure segment 205such as operating parameters data store 270. When an unauthorized reador write occurs to operating parameters data store 270, the module maynotify another module in FHV meter, or in other embodiments, may triggera visual indicator that can be visually inspected. For example, if FHVmeter is implemented as a dedicated computer system attached to a FHV,FHV meter may have a light that is green when no unauthorized reads orwrites has occurred. Upon detection of a unauthorized write, themonitoring module may command the light to change to red, indicatingthat the secure segment has been compromised.

In general, the word module, as used herein, refers to logic embodied inhardware or firmware, or to a collection of software instructions storedon a non-transitory, tangible computer-readable medium, possibly havingentry and exit points, written in a programming language, such as, forexample, C, C++, C#, or Java. A software module may be compiled andlinked into an executable program, installed in a dynamic link library,or may be written in an interpreted programming language such as, forexample, BASIC, Perl, or Python. It will be appreciated that softwaremodules may be callable from other modules or from themselves, and/ormay be invoked in response to detected events or interrupts. Softwaremodules may be stored in any type of computer-readable medium, such as amemory device (e.g., random access, flash memory, and the like), anoptical medium (e.g., a CD, DVD, BluRay, and the like), firmware (e.g.,an EPROM), or any other storage medium. The software modules may beconfigured for execution by one or more CPUs in order to cause FHV meter100 to perform particular operations.

It will be further appreciated that hardware modules may be comprised ofconnected logic units, such as gates and flip-flops, and/or may becomprised of programmable units, such as programmable gate arrays orprocessors. The modules described herein are preferably implemented assoftware modules, but may be represented in hardware or firmware.Generally, the modules described herein refer to logical modules thatmay be combined with other modules or divided into sub-modules despitetheir physical organization or storage.

In one embodiment, FHV meter 100, includes a dedicated computer that isIBM, Macintosh or Linux/Unix compatible. In another embodiment, FHVmeter 100 may be a customized computing device configured only tooperate as a meter in a for-hire vehicle. In another embodiment, FHVmeter 100 may be a module that is part of the internal computing systemof the for-hire vehicle. FHV meter 100 may, in some embodiments, includeone or more central processing units (“CPU”) 210, which may include oneor more conventional or proprietary microprocessors. FHV meter 100 mayfurther include memory 215, such as random access memory (“RAM”) fortemporary storage of information and read only memory (“ROM”) forpermanent storage of information, and general data store 220, such as ahard drive, diskette, or optical media storage device. In certainembodiments, general data store 220 stores data needed for the basicfunctioning of FHV meter. In other embodiments, general data store 220might store historical trip information. Embodiments of general datastore 220 may store data in databases, flat files, spreadsheets, or anyother data structure known in the art. Typically, the modules of FHVmeter 100 are in communication with one another via a standards basedbus system. In different embodiments, the standards based bus systemcould be Peripheral Component Interconnect (PCI), Microchannel, SCSI,Industrial Standard Architecture (ISA) and Extended ISA (EISA)architectures, for example. In another embodiment, FHV meter 100leverages computing and storage services available over the Internet(cloud computing).

In one embodiment, general data store 220 contains a data structure, ordata element, that uniquely identifies the FHV meter. In someembodiments, the data element may be an integer that represents theserial number of the FHV meter. In other embodiments, the data elementmay be a string or a character array that is unique to the FHV meter.For example, the data element might be 12345678 or “09GTR67RXY.” Inother embodiments, the unique identifier may be an object or a datastructure with several elements that when combined represent a uniqueidentifier for the FHV meter. For example, the make and model of the FHVmeter, combined with the license plate number and registration state ofthe FHV may be used in combination to uniquely represent the FHV meter.

FHV meter 100 is generally controlled and coordinated by operatingsystem software, such as the Windows 95, 98, NT, 2000, XP, Vista, Linux,SunOS, Solaris, PalmOS, Blackberry OS, or other compatible operatingsystems. In Macintosh systems, the operating system may be any availableoperating system, such as MAC OS X. In another embodiment, FHV meter 100may be controlled by a proprietary operating system. Conventionaloperating systems control and schedule computer processes for execution,perform memory management, provide file system, networking, and I/Oservices, and may provide a user interface, such as a graphical userinterface (“GUI”) for display, among other things.

FHV meter 100 may include, in some embodiments, device calculationdevice 230 for calculating the distance traveled by the FHV. Devicecalculation device may be a separate computer system from FHV meter 100,or as in the embodiment depicted in FIG. 2, a module of FHV meter 100.For example, distance calculation device 230 may be part of the internalcomputer system of the for-hire vehicle that FHV meter 100 is connected,or it may be a dedicated computer that is connected to FHV meter viainput/output (“I/O”) devices and interfaces 240. Device calculationdevice 230 may receive input pulses representing the number of turns ofthe FHV's wheels. The input pulses, in some embodiments, may be receivedfrom I/O devices and interfaces 240. The input pulses may be generatedby a dedicated device for counting wheel turns, or in some embodiments,the input pulses may be generated by FHV's internal computer system.Distance calculation device 230 may send calculated distance values toCPU 210 which may then in turn be used to calculate fares based onoperating parameters.

FHV meter 100 may include one or more commonly available I/O devices andinterfaces 240, such as for example, a printer, buttons, a keyboard, aLED display, a monitor, a touchpad, a USB port, a RS 232 port and thelike. In one embodiment, I/O devices and interfaces 240 include one ormore display devices, such as a monitor, that allows the visualpresentation of data, such as fare and operation data, to a user. In theembodiment of FIG. 2, I/O devices and interfaces 240 provide acommunication interface to various external devices. For example, inthis embodiment FHV meter 100 is in communication with a distributionnetwork, such as any combination of one or more LANs, WANs, or theInternet, for example, via a wired, wireless, or combination of wiredand wireless, connections via a network interface of I/O devices andinterfaces 240. The communications interface may also include, forexample, ports for sending and receiving data such as a USB port or anRS 232 port. In some embodiments, FHV meter may communicate with one ormore external devices such as the FHV internal computer system, aprinter, a GPS device, etc. by sending and receiving data on ports suchas a USB port or a RS 232 port.

In one embodiment, the FHV meter may have geospatial recognition module250. Geospatial recognition module 250 may include a GPS receiver forreceiving GPS coordinates from GPS satellites. In some embodiments, theGPS coordinates received from geospatial recognition module 250 may usedto calculate fares based on FHV parameters stored in operatingparameters data store 270.

Secure segment 205 of FHV meter 100 may, in some embodiments, include aprivate key 260. Private key 260 may be, in some embodiments, softwareinstructions and/or data used to decrypt data. In one embodiment,private key 260 is hard-coded on firmware such as programmable read-onlymemory (“PROM”) and may be unique to the embodiment of FHV meter 100. Inother embodiments, private key 260 may not be unique and may be the samein one or more embodiments of FHV meter 100. The PROM storing privatekey 260 may be self destructing if tampered with, that is, if the PROMis removed from the FHV, it will snap and self destruct. For example,epoxy may be placed over private key 260 such that it could not beremoved from secure segment 205 without chipping or damaging private key260.

In one embodiment, secure segment 205 of FHV meter may also includecipher engine module 270. Cipher engine module 270 may, in someembodiments, contain software instructions used to decipher coded orencrypted data packets containing FHV parameters. Cipher engine module270 may use private key 260 to decrypt data packets received fromdistribution network 130. Cipher engine module 270 may also includesoftware instructions for extracting FHV parameters and storing them inoperating parameters data store 280. In some embodiments, cipher enginemodule 270 may be hard coded to firmware such as PROM. The PROM storingcipher engine module 270 may be self destructing if tampered with, thatis, if the PROM is removed from the FHV, it will snap and self destruct.For example, epoxy may be placed over cipher engine module 270 such thatit could not be removed from secure segment 205 without chipping ordamaging it.

FHV meter 100 may also include operating parameters data store 280.Operating parameters data store 280 may, in some embodiments, store theoperating parameters by which FHV meter 100 operates. For example, CPU210 may access operating parameters data store 280 when calculatingtime-distance charges or determining surcharges. Operating parametersdata store 280 may be, in some embodiments, a secure data store. In oneembodiment, operating parameter data store 280 may only be accessed forwriting by cipher engine module 270. Thus, while CPU 210 may accessoperating parameters data store 280 for reading FHV operatingparameters, CPU 210 would not be able to perform write operations tooperating parameters data store 280. Accordingly, FHV parameters cannotbe changed by software instructions stored in general data store 220 orsome other data store connected to FHV meter 100. This may, in someembodiments, be accomplished by only wiring the write pins of operatingparameters data store 280 to the firmware containing the softwareinstructions for cipher engine module 270. For example, operatingparameters data store 280 may be a RAM chip whereby only cipher enginemodule 270 is connected to the write pins of the RAM. In someembodiments, operating parameter data store 280 may self destruct ifsomeone tampers with the configuration. In other embodiments, operatingparameter data store 280 may be physically connected to FHV with atamper evident seal that indicates one state if someone tampers withoperating parameter data store 280 and another state if no one hastampered with operating parameter data store 280.

FHV meter 100 may include secure memory 285 and secure CPU 290. Securememory 285 may be a non-transitory, tangible, computer readable mediumsuch as random access memory (“RAM”) for temporary storage ofinformation and read only memory (“ROM”) for permanent storage ofinformation. Secure memory 285 may store software instructions thatcause secure 290 to perform the methods of the embodiments describedherein. FHV meter 100 may also include, in some embodiments, transmitter295. Transmitter 295 may be a wireless transmitter that sends messagesover a network, such as distribution network 130. In one embodiment,transmitter 295 may only send signals and not receive signals fromoutside computer systems. In some embodiments, transmitter 295 may sendsignals generated by secure CPU 290 such as security breach messages, orin other embodiments, it may send data to parameter maintenance computersystem 120 that parameter maintenance computer system 120 may process todetect tampering with FHV meter 100. In other embodiments, transmitter295 may be able to receive certain security signals, such as a “kill”message sent by parameter maintenance computer system 120.

In one embodiment, the FHV meter may implement security measures toensure that secure segment 205 remains in communication with theunsecure portions of FHV meter 100. The security measures may preventinstances of fraud where a person may attempt to replace either securesegment 205 or the unsecure portions of FHV meter 100 with a deviceintended to calculate fraudulent fares. In some embodiments, when theimplemented security measure fails, CPU 210 or secure CPU 290 mayinitiate a shutdown sequence that causes FHV meter 100 to ceaseoperating. In other embodiments, when the implemented security measurefails, CPU 210 may send a security breach message via I/O devices 240that may be transmitted back to parameter maintenance computer system120. In some embodiments, the transmission may be a wirelesscommunication. In some embodiments, the security breach message may betransmitted from secure segment 205 by secure CPU 290 via transmitter295. In other embodiments, the security breach message may be displayedon the monitor of FHV meter 100.

In one embodiment, the security measure may be implemented via asoftware handshake between secure CPU 290 and CPU 210. If the softwarehandshake fails, then CPU 210 will shutdown causing FHV meter 100 tocease operation, or in other embodiments may transmit a security breachmessage to parameter computer system 120. The handshake starts with CPU210 generating a key, or hash, that is stored in memory 215 and known tosecure CPU 290. CPU 210 may then send the hash over to secure CPU 290.Secure CPU 290 may then increment, or otherwise modify the hash,according to an algorithm known both to CPU 210 and to secure CPU 290.Secure CPU 290 may store the incremented hash in secure memory 285before sending it to CPU 210. Upon receipt of the incremented data, CPU210 may then access the previously sent hash, increment it according tothe algorithm, and compare the result to the data received from secureCPU 290. If the incremented data matches the result, the handshakecontinues whereby CPU 210 increments the data received from secure 290,stores it in memory 215, and then sends it to secure CPU 290. Theprocess will repeat until either CPU 210 or secure CPU 290 receives ahash it was not expecting.

One example of the software handshake may be as follows: Both CPU 210and secure CPU 290 are programmed with a handshake algorithm thatincreases the received hash value by 1. CPU 210 starts the handshake bygenerating “5”, storing “5” in memory 215 and then sending “5” to secureCPU 290. Secure CPU 290 receives “5” and determines if that is the knownstarting point for the handshake. Once secure CPU 290 determines thatknown starting point is correct, it generates “6” (5+1), stores “6” insecure memory 285 and then sends “6” to CPU 210. When CPU 210 receives“6”, it pulls the last sent hash out of memory 215, specifically, “5.”CPU 210 then applies the handshake algorithm to arrive at an expectedvalue of “6.” Since the expected value of “6” matches the received valueof “6”, CPU 210 repeats the process by generating a “7”, storing a “7”in memory 215 and then sending “7” to secure CPU 290. Secure CPU 290receives “7” and pulls the last sent hash (“6”) out of secure memory285, applies the algorithm (to arrive at “7”) and then compares theexpected value (“7”) with the received value (“7”). If the code matches,the process repeats. If it anytime CPU 210 or secure CPU 290 do notreceive the expected value, a shutdown sequence may commence renderingFHV meter 100 inoperable.

In one embodiment, instead of a software handshake, a double pollingverification security measure may be employed. In this embodiment, CPU210 may constantly poll secure CPU 290 for a first specific response. IfCPU 210 ever receives a value it does not expect, it will ceaseoperations of FHV meter 100. At the same time, secure CPU 290 may pollCPU 210 for a second specific response. If secure CPU 290 does notreceive the expected response, it may also contain code that initiates ashut down sequence of FHV meter 100.

In another embodiment, an odometer check may be done as a securitymeasure. In such embodiments, secure CPU 290 may receive data fromdistance calculation device 230 and secure memory 285 may store softwareinstructions that estimates the odometer reading of the FHV to which FHVMeter 100 is attached. Also, CPU 210 may be programmed to periodicallycheck the odometer of the vehicle to which the FHV meter is attached. Inother embodiments, CPU 210 may be programmed to access odometerinformation from a third party computer system that maintains odometersreadings of vehicles, such as Department of Motor Vehicles computersystems or CARFAX® computer systems. CPU 210 may then send the odometervalue to secure CPU 290. Secure CPU 290 may then store the odometerreading in secure memory 285. In some embodiments, secure CPU 290 maythen compare the odometer value received from CPU 210 with an estimatedodometer value calculated from the previous odometer received from CPU210. If the estimated odometer value varies substantially (for example,the difference is greater than 10% or 15%) from the odometer valuereceived from CPU 210, secure CPU 290 may then initiate a shutdownsequence, or in other embodiments, send a security breach message toparameter maintenance computer system 120 via transmitter 295.

In some embodiments, data may be sent to parameter maintenance computersystem 120 and it may use the data to determine if there has beentampering with secure segment 205. Parameter maintenance computer system120 may be configured to receive data from a wireless transmitterconnected to CPU 210 on the unsecure portion of the FHV meter and fromtransmitter 295 connected to secure CPU 290. Parameter maintenancecomputer system 120 may then compare the data received to data it wasexpecting to determine if FHV meter was subject to tampering. Forexample, parameter maintenance computer system 120 may receive a firstpredetermined numeric value or code from CPU 210 via I/O devices 240 anda second predetermined numeric value or code from secure CPU 290.Parameter maintenance computer system 120 may then compare the receivedvalues to a matched pair of expected values to determine if securesegment 205 is attached to the proper unsecure portion. For example,parameter maintenance computer system 120 may store the assignment ofthe unsecure portion to secure segment 205 based on the serial numberCPU 210 and the serial number of secure CPU 290 as a pair of values. Thepair of values indicates the assignment of unsecure portion to securesegment 205. On a periodic basis, CPU 210 may send to parametermaintenance computer system 120 a data message containing the serialnumber of the CPU via I/O devices 240. Secure CPU 290 may also send amessage to parameter maintenance computer system 120 via transmitter 295containing the serial number of secure CPU 290. Parameter maintenancecomputer system 120 may then compare the received values to the expectedpair of values for the meter. If values do not match, parametermaintenance computer system 120, in one embodiment, may generate a“kill” message disabling the for-hire vehicle meter. In anotherembodiment, parameter maintenance computer system 120 may issue awarning message if the values do not match.

FIG. 3 is a block diagram of one embodiment of parameter maintenancecomputer system 120. In one embodiment, parameter maintenance computersystem 120 is configured to interface with multiple devices, such asshown in the exemplary network of FIG. 1. Parameter maintenance computersystem 120 may be used to implement certain systems and methodsdescribed herein. The functionality provided for in the components andmodules of parameter maintenance computer system 120 may be combinedinto fewer components and modules, or further separated into additionalcomponents and modules.

In one embodiment, parameter maintenance computer system 120 includes,for example, a server or a personal computer that is IBM, Macintosh, orLinux/Unix compatible. In another embodiment, parameter maintenancecomputer system 120 comprises a laptop computer, smart phone, personaldigital assistant, or other computing device, for example. In oneembodiment, the exemplary parameter maintenance computer system 120includes one or more central processing units (“CPU”) 310, which mayinclude one or more conventional or proprietary microprocessors.Parameter maintenance computer system 120 further includes a memory 315,such as random access memory (“RAM”) for temporary storage ofinformation and a read only memory (“ROM”) for permanent storage ofinformation, and a data store 320, such as a hard drive, diskette, oroptical media storage device. In certain embodiments, data store 320stores FHV meter data and one or more sets of FHV operating parameterdata. Embodiments of data store 320 may store data in databases, flatfiles, spreadsheets, or any other data structure known in the art.Typically, the modules of parameter maintenance computer system 120 arein communication with one another via a standards based bus system. Indifferent embodiments, the standards based bus system could bePeripheral Component Interconnect (PCI), Microchannel, SCSI, IndustrialStandard Architecture (ISA) and Extended ISA (EISA) architectures, forexample. In another embodiment, parameter maintenance computer system120 leverages computing and storage services available over the Internet(cloud computing).

Parameter maintenance computer system 120 is generally controlled andcoordinated by operating system and/or server software, such as theWindows 95, 98, NT, 2000, XP, Vista, Linux, SunOS, Solaris, PalmOS,Blackberry OS, or other compatible operating systems. In Macintoshsystems, the operating system may be any available operating system,such as MAC OS X. In another embodiment, parameter maintenance computersystem 120 may be controlled by a proprietary operating system.Conventional operating systems control and schedule computer processesfor execution, perform memory management, provide file system,networking, and I/O services, and provide a user interface, such as agraphical user interface (“GUI”), among other things.

The exemplary parameter maintenance computer system 120 may include oneor more commonly available input/output (I/O) interfaces and devices330, such as a keyboard, mouse, touchpad, and printer. In oneembodiment, the I/O devices and interfaces 330 include one or moredisplay devices, such as a monitor, that allows the visual presentationof data to a user. More particularly, a display device provides for thepresentation of GUIs, application software data, and multimediapresentations, for example. In the embodiment of FIG. 3, the I/O devicesand interfaces 330 provide a communication interface to various externaldevices. For example, in this embodiment parameter maintenance computersystem 120 is in communication with distribution network 130, such asany combination of one or more LANs, WANs, or the Internet, for example,via a wired, wireless, or combination of wired and wireless, connectionsvia a network interface of the I/O devices and interfaces 330.

In the embodiment of FIG. 3, parameter maintenance computer system 120also includes several application modules that may be executed by CPU310. The software code of the modules may be stored on a non-transitorycomputer-readable medium such as for example, RAM or ROM. Moreparticularly, the application modules include FHV configuration module340 and data packet generation module 350. In some embodiments,parameter maintenance computer system 120 may be operated by aregulatory agency, or in some embodiments, by a FHV fleet operator underthe supervision of a regulatory agency. Parameter maintenance computersystem 120 may, in some embodiments, be secured via a username andpassword. In other embodiments, parameter maintenance computer system120 may be located in physically secure location such that onlyauthorized personnel may access parameter maintenance computer system120.

In one embodiment, FHV configuration module 340 may comprise softwarecode executable by CPU 310 that handles the configuration of for-hirevehicles. In some embodiments, configuration of for-hire vehicles(“FHVs”) is done through the creation and modification of FHV operatingparameters. In some embodiments, the FHV operating parameters may bedefined as indicated above. In some embodiments, FHV operatingparameters may be defined and modified through the use of a userinterface generated by FHV configuration module 340. FHV configurationmodule 340 may generate a user interface and present it to a user ofparameter maintenance system 120 so that the user may assign values tovarious FHV parameters. Once a user defines the parameters, they may bestored to data store 320 or they may be sent to data packet generationmodule 350.

In one embodiment, data packet generation module 350 may comprisesoftware code executable by CPU 310 that handles the generation of datapackets that may be deployed via distribution network 130 to FHV meterssuch as FHV meter 100. The generation of the data packet may be in aformat the FHV meter can interpret. For example, the data packet may bean XML file, text file, serialized object, COM object, byte stream, orany other data format known in the art. The data packet generationmodule 350 may generate a data packet unique to the target FHV meter. Inother embodiments, data packet generation module 350 may generate a datapacket that may be used by several different FHV meters.

FIG. 4 shows the temporal flow of data for generating secure datapackets for FHV parameters in one embodiment of parameter maintenancecomputer system 120. First, in box 410, parameter maintenance computersystem 120 receives FHV operating parameters. In general, the FHVoperating parameters may be defined by a regulatory agency that controlsand regulates for-hire vehicles (“FHVs”). The operating parameters maybe received by parameter maintenance computer system 120 through the useof a user interface generated by FHV configuration module 340. In someembodiments, once parameter maintenance computer system 120 receives theFHV parameters, it may store them in data store 320.

Next, in box 420 parameter maintenance computer system 120 generatesdata packets for distribution or deployment to FHV meter 100. The datapackets generated by parameter maintenance computer system 120 maycontain the FHV operating parameters received in box 410. In oneembodiment, several FHV parameters are included in a data packet. A datapacket may be, in some embodiments, the group of FHV operatingparameters that are to be distributed to a particular FHV meter. In oneembodiment, parameter maintenance computer system 120 may generate adifferent data packet for each FHV meter in distribution network 130. Inother embodiments, it may generate a data packet for more than one FHVmeter in the distribution network. In such embodiments, the FHV metersof distribution network 130 may share the same private key fordecryption purposes.

In one embodiment, each generated data packet contains a header. Theheader may contain metadata used by FHV meters in distribution network130 containing a unique identifier corresponding to the FHV meter thatshould read the data packet. For example, if parameter maintenancecomputer system 120 generates a data packet for FHV meter 123456578, thedata packet might contain metadata indicating that the data packet isfor FHV meter 12345678. The metadata of the header may be configured tomatch the unique identifier scheme of the FHV meters in distributionnetwork 130.

In some embodiments, the data packet may be generated by parametermaintenance computer system 120 as an XML file. The root node of the XMLfile may correspond to metadata. For example, the root node may containthe unique identifier of the FHV meter for which the data packet wasgenerated. The first child nodes of the root node (“second level nodes”)may correspond to one or more group-FHV operating parameters. The secondlevel nodes may, for example, define the validity duration of a group ofFHV operating parameters, or in other embodiments, geospatial validityof a group of FHV operating parameters. The child nodes of the secondlevel nodes (“third level nodes”) may contain FHV operating parameterssuch as time and distance-traveled parameters, geospatial pointparameters, variable operating cost surcharge parameters, fareinitiation parameters or fare termination parameters. In otherembodiments, the data packet may be generated as a text file, serializedobject, data stream, or any other data format known in the art suitablefor transferring data between computer systems. In some embodiments, thedata packet may not be hierarchal, but instead defined in a flatstructure with a series of name-value pairs indicating the various FHVparameters and their associated values.

In box 430, parameter maintenance computer system 120 seals and securesthe data packets generated in box 420. In one embodiment, parametermaintenance computer system 120 seals and secures the data packets usingan asymmetrical encryption means such as public-private key encryption.In such embodiments, parameter maintenance computer system 120 mayencrypt the data packet based on a public key associated with FHV meter100. In some embodiments, the public key of FHV meter 100 may be uniqueto the FHV meter. For example, FHV meter with serial number 123 may havea different public key than FHV meter with serial number 987. In otherembodiments, the public key for more than one FHV meter may be the same.For example, all of the FHV meters of a particular manufacturer, or fora particular for-hire vehicle fleet operator, may share the same publickey. Parameter maintenance computer system 120 may seal and secure thedata packets by using a standard encryption algorithm such as forexample, Data Encryption Standard (DES), Advanced Encryption Standard(ADS), Pretty Good Privacy (PGP), International Data EncryptionAlgorithm (IDEA), Blowfish, RCS, CAST, etc. One skilled in the art canappreciate that any encryption algorithm may be used to seal and securethe data packets generated by parameter maintenance computer system 120.

Moving to box 440, once the data packet has been sealed and secured, itmay be distributed to FHV meters in distribution network 130. Thedistribution of packets may vary depending on the embodiment. Forexample, in one embodiment data packets may be transferred to a portablenon-transient computer readable medium such as CD-ROM, diskette, or USBflash drive. In such an embodiment, an individual under a regulatoryagency's authority supervision and control may manually load the sealedand secure data packets to each FHV meter. In some embodiments, onemedium may be generated for each FHV meter. This may occur inembodiments where the FHV meter is dedicated computer system. Forexample, in some embodiments, a data packet may be loaded onto aplurality of USB flash drives, each of the USB flash drivescorresponding to one of the FHV meters in distribution network 130. Anagent of the regulatory agency may insert the USB flash drive into theUSB port of the FHV meter intended to be loaded with the data packetstored on the USB flash drive. In such embodiments, the USB flash drivemay act as a USB Dongle, that is, the FHV meter may only operate whenthe USB flash drive is inserted into the FHV meter. The agent may thenseal the USB Dongle to the FHV meter using a visual indicator oftampering such as color coded self destructible tape, special plastictie, special metal tie, or seal. The visual indicator may then act asevidence of tampering; if the visual indicator is broken, it will serveas an indication that the USB Dongle may have been tampered with.

In other embodiments, distribution of sealed and secure data packets mayoccur over a wireless network. In such embodiments, each FHV meter indistribution network 130 may have a wireless receiver capable ofreceiving a wireless network signal. Parameter maintenance computersystem 120 may broadcast, on a periodic basis, data packets for variousFHV meters. In some embodiments, the FHV meters may listen for all datapackets broadcast by parameter maintenance computer system 120. Usingthe header information of the data packet, the FHV meter may thendetermine if the data packet should be used to update its parameters bycomparing the unique identifier information of the data packet to theunique identifier information stored in general data store 220.

In other embodiments, FHV meters may run server software, such as atelnet server, socket server, or any other means of communicating over aTCP port that allows for communications with parameter maintenancecomputer system 120. In such embodiments, the FHV meters of distributionnetwork 130 may be assigned a dedicated IP address. Parametermaintenance computer system 120 may store, in data store 320, the IPaddress, the unique identifier, and in some embodiments the public key,associated with FHV meter 100. The stored data may then be used todistribute the data packet to a specific FHV meter such as FHV meter100. For example, parameter maintenance computer system 120 may generatea data packet and include in the header the unique identifier of FHVmeter 100. After the data packet is generated, parameter maintenancecomputer system 120 may seal the data packet according to the publickey. Then, parameter maintenance computer system 120 may use the IPaddress of the FHV meter to start a session with the FHV meter and opena port for communication. Parameter maintenance computer system 120 maythen transfer the data packet directly to its intended target FHV meter.

In other embodiments, FHV meter 100 may pull data packets from parametermaintenance computer system 120 as opposed to parameter maintenancecomputer system 120 pushing data packets to FHV meter 100. For example,FHV meter 100 may, via a wireless connection, poll parameter maintenancecomputer system 120 on a periodic basis to determine if any data packetshave been generated since the last request. The request may include, forexample, the unique identifier of the FHV meter. Parameter maintenancecomputer system 120 may respond to the request by sending a data packetcorresponding to the unique identifier of the FHV meter. In someembodiments, parameter maintenance computer system 120 may respond witha null message, or a message indicating no data packets were generatedsince the last request. In some embodiments, FHV meter 100 may make anupdate request daily, every other day, or weekly. In some embodiments,the FHV meters within distribution network 130 may be configured to makeupdate requests at different points during an update period so thatnetwork traffic is minimized. For example, FHV meter 100 may make anupdate request daily at 9 AM, FHV meter 101 may make an update requestdaily at 10 AM, and FHV meter 102 may make an update request at daily 11AM.

The distribution methods of sealed and secured data packets describedherein with reference to box 440 are meant as examples and should not beinterpreted as the sole means for distributing data packets withindistribution network 130. It can be appreciated that the distribution ofdata between the systems of distribution network 130 may vary accordingto the needs and limitations of the particular embodiment and thedistribution methods described herein may be tailored to satisfy theneeds, and work within the limitations, of any particular distributionnetwork.

FIG. 5 is a flowchart showing the temporal flow of data for processing asecure data packet in one embodiment of FHV meter 100. Starting in box510, FHV meter 100 receives a data packet containing FHV operatingparameters. As described above, there are numerous means for receivingthe data packet, including but not limited to, receipt from a computermedium directly connected to the FHV meter and receipt of the datapacket via a wireless receiver. Once the data packet has been received,FHV meter must process the data packet.

Processing begins, in one embodiment, by validating the data packet inbox 520. Validation of data packets may start, in one embodiment, byexamining the metadata header of the data packet for a valuerepresenting the unique identifier of the data packet's target FHVmeter. If the data packet contains a unique identifier not matching theunique identifier of FHV meter 100, processing stops and the data packetmay be discarded, or deleted, from memory 215. If the data packetcontains a unique identifier matching the unique identifier of FHV meter100, FHV meter 100 may continue to validate the packet by decrypting it.In other embodiments, the data packet does not contain a metadataheader, or the metadata header may not include a unique identifier. Insuch embodiments, the validation process may begin by FHV meter 100attempting to decrypt the data packet. For example, cipher engine module280 may attempt to decrypt the data packet using private key 260. Oncedecrypted, FHV meter 100 may attempt extract operating parameters fromthe data packet. If FHV meter 100 cannot extract usable operatingparameters from the data packet, then the data packet fails validation.In such embodiments, the data packet may then be discarded, or deletedfrom RAM. In some embodiments, if the data packet fails validation, FHVmeter 100 may shut down or send a message to parameter maintenancecomputer system 120 that it received a data packet that failedvalidation.

Once the packet has been validated, FHV meter 100 extracts operatingparameters from the data packet in box 530 if it has not already done soduring the validation step. The extraction of operating parametersdepends on the embodiment. For example, if the data packet was generatedas an XML file, FHV meter 100 may analyze the XML file to determine theFHV operating parameters. In other embodiments, if the data packet is aserialized object, FHV meter 100 may desterilized the object, and thenextract the FHV parameters using the object's interface. In otherembodiments, the data packet may be implement as a byte stream, in whichcase, FHV meter 100 may parse the byte stream in order to determine theoperating parameters.

In box 540, once the operating parameters have been extracted, they maybe stored in operating parameters data store 270. In box 550, the storedoperating parameters may be accessed by CPU in order to calculate fares.The fares may be calculated based on stored time and distance-traveledparameters, geospatial point parameters, variable operating costsurcharge parameters, fare initiation parameters or fare terminationparameters. The stored parameters may be used in conjunction with othermodules of FHV meter 100 to calculate fares such as, for example,distance calculation device 230 or geospatial recognition module 250.

All of the methods and tasks described herein may be performed and fullyautomated by a computer system. The computer system may in some casesinclude multiple distinct computers or computing devices (e.g., physicalservers, workstations, storage arrays, etc.) that communicate andinteroperate over a network to perform the described functions. Eachsuch computing devices typically includes a processor (or multipleprocessors) that executes program instructions or modules stored in amemory or other non-transitory computer-readable storage medium. Thevarious functions disclosed herein may be embodied in such programinstructions, although some or all of the disclosed functions mayalternatively be implemented in application-specific circuitry (e.g.,ASICs or FPGAs) of the computer system. Where the computer systemincludes multiple computing devices, these devices may, but need not, beco-located. The results of the disclosed methods and tasks may bepersistently stored by transforming physical storage devices such assolid state memory chips and/or magnetic disks, into a different state.

The foregoing description details certain embodiments of the invention.It will be appreciated, however, that no matter how detailed theforegoing appears in text, the invention can be practiced in many ways.It should be noted that the use of particular terminology whendescribing certain features or aspects of the invention should not betaken to imply that the terminology is being re-defined herein to berestricted to including any specific characteristics of the features oraspects of the invention with which that terminology is associated. Thescope of the invention should therefore be construed in accordance withthe appended claims and any equivalents thereof.

What is claimed is:
 1. A for-hire vehicle computer system comprising: areceiver configured for receiving signals from a network-based parameterdistribution system; a first processor; a tangible firstcomputer-readable-medium storing unique identifier data; atamper-evident, tangible, second computer-readable-medium storing:decryption protocol data; current for-hire vehicle operating parameterdata; first software instructions that when executed cause the processorto: access an encrypted data packet comprising one or more updatedfor-hire vehicle operating parameters; decrypt the encrypted data packetbased on a decryption protocol; determine if the for-hire vehiclecomputer system should operate according to the one or more updatedfor-hire vehicle operating parameters based at least in part on theunique identifier data; extract the one or more updated for-hire vehicleoperating parameters from the data packet; and, modify the currentfor-hire vehicle operating parameter data based on the one or moreupdated for-hire vehicle operating parameters.
 2. The for-hire vehiclecomputer system of claim 1, further comprising a removable, non-tamperevident portion.
 3. The for-hire vehicle computer system of claim 2wherein the non-tamper evident portion comprises a second processor anda non-transitory, tangible, third computer-readable-medium.
 4. Thefor-hire vehicle system of claim 3, wherein the first processor and thesecond processor execute a security handshake.
 5. The for-hire vehiclecomputer system of claim 1, wherein the software instructions furthercause the processor to calculate a for-hire vehicle fare based on themodified current for-hire vehicle operating parameter data.
 6. Thefor-hire vehicle computer system of claim 1 wherein the data packet isencrypted using an algorithm specific to the for-hire vehicle computersystem.
 7. The for-hire vehicle computer system of claim 1 wherein thetamper-evident, tangible, computer-readable-medium comprises a tamperingindicator indicating a first state if the tamper evident, tangible,computer-readable-medium has been tampered with, and a second state ifthe tamper evident, tangible, computer-readable-medium is tamper free.8. The for-hire vehicle computer system of claim 1 wherein at least oneof the one or more updated for-hire vehicle operating parametersindicate a valid time period for the one or more updated for-hirevehicle operating parameters.
 9. The for-hire vehicle computer system ofclaim 1 wherein at least one of the one or more updated for-hire vehicleoperating parameters indicates a geospatial point based surcharge. 10.The for-hire vehicle computer system of claim 1 wherein at least one ofthe one or more updated for-hire vehicle operating parameters indicatesa variable operational surcharge.
 11. The for-hire vehicle computersystem of claim 1 further comprising a USB port.
 12. The for-hirevehicle computer system of claim 11, wherein the software instructionsfurther cause the processor to access the encrypted data packet by theUSB port.
 13. A method of modifying the operation of a for-hire vehiclecomputer system, comprising: accessing a security protocol associatedwith a for-hire vehicle computer system; accessing a plurality offor-hire vehicle operating parameters, the for-hire vehicle operatingparameters indicating the rules of operation of the for-hire vehiclecomputer system; generating, by a parameter maintenance computer system,a data packet comprising an indication of the for-hire vehicle operatingparameters; securing, by the parameter maintenance computer system, thedata packet according to the security protocol thereby creating a securedata packet; and, transferring the secure data packet to the for-hirevehicle computer system.
 14. The method of claim 13 wherein the securityprotocol associated with the for-hire vehicle computer system in anencryption protocol.
 15. The method of claim 13 wherein the securityprotocol specifies an algorithm for securing the data packet that isunique to the for-hire vehicle computer system.
 16. The method of claim13 wherein the plurality of for-hire vehicle operating parameterscomprises a time parameter, the time parameter indicating a period oftime for which the for-hire vehicle computer system should operateaccording to the plurality of for-hire vehicle operating parameters. 17.The method of claim 16 wherein the plurality of for-hire vehicleoperating parameters comprises mutually exclusive sets of operatingparameters, the mutually exclusive sets of operating parameters eachindicating a non-overlapping time period for which the for-hire vehiclecomputer system should operate according to for-hire vehicle operatingparameters of each mutually exclusive set of operating parameters. 18.The method of claim 13 wherein the plurality of for-hire vehicleoperating parameters comprises a geospatial point based surcharge. 19.The method of claim 13 wherein the plurality of for-hire vehicleoperating parameters comprises a variable operational surcharge.
 20. Themethod of claim 13 wherein the transferring is performed wirelessly. 21.The method of claim 13 wherein the transferring comprises: copying, bythe parameter maintenance computer system, the secure data packet to anon-transitory, computer readable medium; and connecting thenon-transitory computer readable medium to the for-hire vehicle computersystem.
 22. A for-hire vehicle computer system comprising: means forstoring a private encryption key; means for decrypting data packetsencrypted with a public key associated with the for-hire vehiclecomputer system to determine for-hire vehicle operating parameters;means for detecting evidence of tampering with the storing means anddecrypting means; means for calculating for-hire vehicle fares based onthe for-hire vehicle operating parameters.
 23. The for-hire vehicle ofclaim 22 further comprising: means for executing a software securityhandshake.